Heuristics processing

ABSTRACT

An indication is provided to a transaction participant as part of a message originating from a transaction coordinator. The message indicates that the transaction coordinator supports a heuristic response. The transaction coordinator coordinates commitment of transactions as requested by an application in response to a determination by the transaction participant of a heuristic outcome. Heuristic outcomes include situations where transaction participants determine they are unable to honor transactional prior prepared commitments made to the transaction coordinator during first prepare phases of two-phase commits associated with the transactions. The heuristic response is received from the transaction participant in association with a transaction coordinated by the transaction coordinator and indicates that the transaction participant is unable to honor a transactional prior prepared commitment made by the transaction participant during a first prepare phase of a two-phase commit associated with the transaction coordinated by the transaction coordinator as requested by the application.

RELATED APPLICATIONS

This application claims priority to and claims the benefit of EuropeanPatent Application Serial No. EP08157005.3 titled “HEURISTICPROCESSING,” which was filed in the European Patent Office on May 27,2008, and which is incorporated herein by reference in its entirety; andthis application is a continuation of and claims priority to and claimsthe benefit of U.S. patent application Ser. No. 12/472,683 titled“HEURISTICS PROCESSING,” which was filed in the United States Patent andTrademark Office on May 27, 2009, which has a status of “Allowed,” andwhich is incorporated herein by reference in its entirety.

BACKGROUND

The present invention relates to transaction support and moreparticularly to heuristic transactional support.

The WS-AtomicTransaction (WS-AT) specification, standardized by OASIS®,describes web services protocol messages for distributed two phasecommit (2PC). It is inspired by the distributed transaction processing(XA) and object transaction service (OTS) specifications each of whichrender 2PC messages for specific scenarios. Both XA and OTS definemessages and state transitions for “heuristic” outcomes; that is, whenthe transaction participant is unable to honor the commitment it made inthe first (prepare) phase of 2PC. WS-AT does not do this because one ofthe author companies declared it “out of scope” for the interoperabilityscenarios their products would support.

BRIEF SUMMARY

Nevertheless, there are others who desire the provision of heuristicsupport. Any solution catering for heuristics however, would extend theWS-AT specification and would not be understood by a true WS-ATimplementer. Consequently a WS-AT provider that implements any heuristicsupport should do so in a way that is sympathetic to the capability ofits transactional partner.

Previously a participant may have been able to receive information thata heuristic outcome has occurred, but may not have been able tocommunicate such information to a transaction coordinator because theparticipant may not be certain that the coordinator supported aheuristic outcome. Further in the WS-AT protocol there was no messagefor communicating the information defined.

According to a first aspect, there is provided a method, comprising:receiving, at a transaction participant, a message from a transactioncoordinator comprising an indication as to whether the transactioncoordinator supports a heuristic response; determining from a messageelement in the message whether the transaction coordinator supportsheuristics, where the message element is ignorable by transactionparticipants that are incapable of communicating the heuristic responseto the transaction coordinator; and responsive to determining that aheuristic outcome has occurred and determining that the transactioncoordinator supports heuristics, sending the heuristic response to thetransaction coordinator, where the heuristic response indicates that thetransaction participant is unable to honor a transactional priorcommitment to the transaction coordinator.

In one embodiment, the message comprises a transaction protocol message.For example, the protocol message may be one which informs thetransaction participant that a transaction has been registered with thetransaction coordinator. Another example is a prepare message sent aspart of a two phase commit protocol.

In one embodiment, the message element comprises a reference parameterwithin a coordination service's endpoint reference. The coordinationservice is preferably part of the transaction coordinator and theendpoint reference preferably identifies how the transactioncoordination service can be reached.

In one embodiment, the message element comprises part of a body of thetransaction protocol message.

In one embodiment, the message element is within a coordination contextof an application initiated message, the coordination context comprisingan element inserted into the application initiated message by thetransaction coordinator. A coordination context preferably provides theinformation useable by the transaction participant in order tocommunicate with the transaction coordinator for the purpose ofparticipating in a particular transaction.

According to another aspect, there is provided a method, comprising:providing, via a transaction coordinator, an indication to a transactionparticipant as part of a message originating from the transactioncoordinator, where the message indicates that the transactioncoordinator supports a heuristic response and where the message isignorable by transaction participants that are incapable ofcommunicating a heuristic outcome to the transaction coordinator andwhere the heuristic response from the transaction participant indicatesthat the transaction participant is unable to honor a transactionalprior commitment to the transaction coordinator.

The invention provides a mechanism for a transaction coordinator toindicate to a transaction participant that it supports a heuristicoutcome—i.e. a course of action has occurred which means that thetransaction participant is unable to honor a transactional priorcommitment to the transaction coordinator. The mechanism is such that aparticipant that is incapable of communicating a heuristic outcome canignore any such indication. A participant may be incapable because itdoes not understand the concept of a heuristic outcome at all or becauseit does not have the ability to inform a transaction coordinator thatone has occurred.

According to one embodiment, providing the indication to the transactionparticipant as part of the message originating from the transactioncoordinator, where the message indicates that the transactioncoordinator supports a heuristic response comprises: augmenting themessage with a message element originating from the transactioncoordinator, where the message element indicates that the transactioncoordinator supports the heuristic response.

In one embodiment, the coordinator may augment a protocol messageoriginating from the transaction coordinator. In another embodiment, themessage element comprises a coordination context inserted into anapplication initiated message by the transaction coordinator.

According to another aspect, there is provided an apparatus, comprising:a transaction manager configured to receive, at a transactionparticipant, a message from a transaction coordinator comprising anindication as to whether the transaction coordinator supports aheuristic response; determine from a message element in the messagewhether the transaction coordinator supports heuristics, where themessage element is ignorable by transaction participants that areincapable of communicating the heuristic response to the transactioncoordinator; and responsive to determining that a heuristic outcome hasoccurred and determining that the transaction coordinator supportsheuristics, send the heuristic response to the transaction coordinator,where the heuristic response indicates that the transaction participantis unable to honor a transactional prior commitment to the transactioncoordinator.

According to another aspect, there is provided an apparatus, comprising:a transaction manager associated with a transaction coordinator, wherethe transaction manager is configured to: provide an indication to atransaction participant as part of a message originating from thetransaction coordinator, where the message indicates that thetransaction coordinator supports a heuristic response and where themessage is ignorable by transaction participants that are incapable ofcommunicating a heuristic outcome to the transaction coordinator; andreceive the heuristic response from the transaction participant thatindicates that the transaction participant is unable to honor atransactional prior commitment to the transaction coordinator.

The invention may be implemented in a computer program product.According to another aspect, there is provided a computer programproduct for heuristic processing, comprising: a computer readablestorage medium having computer readable program code embodied therewith,where the computer readable program code when executed on a computercauses the computer to: receive a message from a transactioncoordinator; determine from a message element in the message whether thetransaction coordinator supports heuristics, where the message elementis ignorable by a transaction participant that is incapable ofcommunicating a heuristic response to the transaction coordinator; andresponsive to determining that a heuristic outcome has occurred anddetermining that the transaction coordinator supports heuristics, sendthe heuristic response to the transaction coordinator.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

A preferred embodiment of the present invention will now be described,by way of example only, and with reference to the following drawings:

FIG. 1 illustrates a component diagram of an environment in which apreferred embodiment of the present invention can be implemented;

FIG. 2 illustrates example messaging for communication that may takeplace between systems 100 and 150 of FIG. 1 in accordance with the WS-ATspecification;

FIG. 3 illustrates, in accordance with a preferred embodiment of thepresent invention, the communication that takes place between systems100 and 150 of FIG. 1; and

FIGS. 4 and 5 illustrate the processing of the present invention, inaccordance with a preferred embodiment.

DETAILED DESCRIPTION

FIG. 1 provides an overview of an environment in which a preferredembodiment of the present invention can be implemented. A system 100comprises an application 110 which initiates a transaction withapplication 130 on system 150. The transaction is managed by transactionmanagers (TMs) 120 and 140, with TM 120 acting as transactioncoordinator and TM 140 being a transaction participant. The transactionmay involve accessing one or more resources (e.g. databases 115, 125) onthe coordinator and participant sides. Such a transaction is performedusing the two-phase commit (2PC) protocol.

FIG. 2 illustrates, in more detail, the communication that may takeplace, between systems 100 and 150, in accordance with the WS-ATspecification. The transaction manager 120 comprises, on the requestingside of a registration service 160, a transaction manager component 165and a WS-AT Co-ordination Service 170. Application 110 is a requestingapplication. On the provider side, transaction manger 140 comprises atransaction management component 175 and a WS-AT participant service180. Application 130 is a provider of a service requested by application110.

At step 1, application requester 110 issues a “begin transaction”request to the transaction manager component 165. This causestransaction manager component 165 to create a co-ordination context forthe transaction at step 2. This includes an identifier for thetransaction, the endpoint reference (EPR) of the requestingenvironment's transaction registration service, and information aboutthe transaction regarding security, reliability etc. At step 3,application requester 110 issues a business request, within the contextof the initiated transaction (i.e. the generated context is propagatedas part of the business request), to application provider 130. Thetransaction context created in step 2 is propagated in the header of thebusiness request, without changing the payload of the business request.

At step 4, application provider 130 invokes transaction managercomponent 175. This causes transaction manager component 175 to registeritself with transaction manager 120's registration service 160 (step 5).This registration request includes the transaction manager (participant)140's end-point reference (EPR). An EPR includes the address that is tobe used to reach the transaction manager 140 and may also includeadditional reference parameters that are not required to be understoodby the consumer of the EPR; for example, a transaction participantidentifier (id).

Receipt of the registration request by the registration service 160causes the registration service 160 to send a response at step 6 to thetransaction manager component 175. The response includes the EPRassociated with the coordinating transaction manager 120. At this pointthe transaction coordinator and participants have exchanged the EPRsthat they will address during 2PC protocol messaging.

At step 7, application requester 110 issues a commit request to thetransaction manager component 165. This indicates that applicationrequester 110 has completed its work and wishes for the transaction tobe completed.

At step 8, the transaction manager component 165 issues a preparerequest to the WS-AT Co-ordination service 170 which is thencommunicated at step 9 to the WS-AT Participant Service 180.

When the WS-AT Participant Service 180 can guarantee that it couldcommit the work requested, it informs the WS-AT Co-ordination Service170 that it is “prepared” (step 10).

At step 11, the WS-AT Co-ordination Service 170 issues a commit requestto the WS-AT Participant Service 180.

Some time later, when application provider 130 has finished processingthe request received from application requester 110, the WS-ATParticipant Service 180 informs the WS-AT Co-ordination Service 170 thatit has committed the transaction (step 12). This is communicated at step13 to the transaction manager component 165 which informs theapplication requester 110 at step 14.

Thus as indicated above, when system 150 can guarantee that it isprepared to do the work requested by system 100, it will inform system100 that it is “prepared”. At this point, system 150 is fully engaged todo the work requested, when system 100 issues a “commit” request.

Sometimes, however, circumstances occur which are beyond system 150'simmediate control. For example, a network link between system 150 anddatabase 125 may break, meaning that system 150 is unable to actuallycomplete the transaction that it has prepared for. In such a situation,an administrator may make a unilateral decision to rollback the work inthe database. Thus when the commit request is received, system 150 isunable to honor this request.

Equally, an administrator may make a decision to commit the databasework which the Coordinating Transaction Manager 120 then requests beaborted.

Ideally the system 150 would, in either case, respond to the system 100with a “heuristic” response. As such, the system 150 may inform thesystem 100 that it is unable to take the expected course of action; inother words, the system 150 has taken a unilateral course of action,despite its previous guarantee, which is inconsistent with thecoordinated outcome.

This is illustrated in FIG. 3, where step 10 a shows a heuristic actionbeing taken (perhaps as a result of administrative intervention). Thiscauses, at step 12, the WS-AT Participant Service to communicate theheuristic abort to the WS-AT Co-ordination Service. This is then in turncommunicated at step 13 to the TM Component 165.

Since protocol messages may be lost in an unreliable network, theparticipant is required to remember its heuristic decision until told bythe Coordinator that it may forget. Steps 14 and 15 show aForget/Forgotten protocol exchange. Upon sending the Forgotten message,the participant may discard all state related to the transaction. Step16 shows the final outcome being communicated back to the applicationrequester 110. Step 16 may occur before steps 14 and 15.

As discussed, the communication between the two systems takes placeaccording to the 2PC protocol defined by the WS-AT specification. WS-ATdoes not, however, define any messages or support for heuristics. Anextension to the WS-AT specification is envisaged herein as discussedabove with reference to FIG. 3.

Since the provision of heuristic support is an extension to the WS-ATspecification, not all transaction coordinators will recognise aheuristic response from a WS-AT Participant Service.

The invention therefore provides, in accordance with a preferredembodiment, a way for a transaction coordinator to indicate to atransaction participant that it supports a heuristic response.

Referring back to FIG. 3, at step 6, the transaction manager 120augments its coordinator EPR with additional information indicatingwhether or not it supports heuristics (indication). The receivingtransaction manager 140 may then use such information to determinewhether or not (should the situation arise) to issue a heuristicresponse to the transaction manager 120. Augmentation of the EPR at step6 is one example. Another possible place to augment the EPR is at step9. Preferably such information is placed as a reference parameter in theEPR provided by the coordinator. Such reference parameters are notrequired to be understood by the EPR consumer (i.e. the transactionparticipant) but may be interpreted by an implementation that has beenextended to support heuristics. Another possibility is for theindication to be included as a different optional and ignorableextension to a protocol message (e.g. register response or prepare). Yetanother option is to include this information as an optional andignorable part of the coordination context propagated at step 3 of FIG.2 and FIG. 3.

When services interact via simple object access protocol (SOAP)messages, the EPR addressing information (including referenceparameters) may be held within a SOAP header and look generally asfollows:

<soap: header>  <wsa: From>   [address]   [reference parameters,including that heuristics are supported]  </wsa: From>  <wsa: To>address </wsa:To> </soap: header>

The particular protocol request being sent may then be contained withinthe SOAP body of the message.

  <soap: body>  <wsat:RegisterResponse>... </wsat:RegisterResponse></soap: body>

It should be appreciated that it is not essential that the informationis communicated as part of the EPR. For example, the transactioncoordinator may instead use the optional, ignorable extension element inthe wsat:RegisterResponse or wsat:Prepare message to indicate itssupport for this extension. As such, the “capability” of the coordinatormay be communicated in a fashion that may be understood by a consentingparticipant but does not need to be understood by a generic participant.

HeuristicRollback is illustrated here but the same principles apply toother potential heuristic outcomes, such as HeuristicCommit andHeuristicHazard for example. The latter indicates a transient conditionand is returned when the WS-AT participant has temporarily lostconnectivity with the back-end resource manager (e.g. database).Subsequent re-sent <wsat:Commit/>or <wsat:Rollback>requests may resolveto the actual outcome for the participant.

FIGS. 4 and 5 illustrate (in accordance with a preferred embodiment) away in which a transaction participant makes use of the informationprovided to it (with respect to heuristics) by a transactioncoordinator.

With reference to FIG. 4 first, a transaction participant receives anindication from a transaction coordinator that it supports heuristics(step 200). This information is then stored away at step 210 for lateruse. Such information may arrive from the coordinator as an EPRreference, may be sent separately, or may be provided in some other way.Such information is transmitted in such a way that it may be ignored bya generic (i.e. unaware) participant. Transmission as an EPR referenceparameter is particularly suitable in this respect since an unawareparticipant may choose to ignore any parameters that it does notrequire.

As shown in FIG. 5, a heuristic outcome to a transaction between thecoordinator and participant may later occur (step 300). If this is so,then it is determined at step 310 (using any indication previouslystored as per FIG. 4) whether such an outcome is supported by thetransaction coordinator. If it is, then the heuristic outcome iscommunicated to the coordinator at step 320. If it does not, thenprocessing may continue as if the heuristic outcome did not occur (step315).

Heuristics outcomes are used if both parties in the transaction havethis capability. A coordinator that supports heuristic outcomes mustalways be prepared to work with a participant that does; similarly, aparticipant that supports heuristic outcomes may report them to acoordinator that has indicated its support for heuristic outcomes asdescribed above.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java™, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modems and Ethernet cards are just a few of thecurrently available types of network adapters.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

It should be appreciated that whilst the invention is described withinthe context of WS-AT, this is by way of example only and no limitationis intended.

What is claimed is:
 1. A computer program product, comprising: acomputer readable storage medium having computer readable program codeembodied therewith, where the computer readable program code whenexecuted on a computer causes the computer to: provide, via atransaction coordinator, an indication to a transaction participant aspart of a message originating from the transaction coordinator, wherethe message indicates that the transaction coordinator, that coordinatescommitment of transactions as requested by an application, supports aheuristic response from the transaction participant that is sent to thetransaction coordinator during coordination of the transactions asrequested by the application in response to a determination by thetransaction participant of a heuristic outcome, where heuristic outcomescomprise situations where transaction participants determine they areunable to honor transactional prior prepared commitments made to thetransaction coordinator during first prepare phases of two-phase commitsassociated with the transactions, and the transactional prior preparedcommitments comprise indications to the transaction coordinator that thetransaction participants are prepared during the first prepare phases ofthe two-phase commits to commit respective portions of the transactionswhen instructed by the transaction coordinator, and where the message isignorable by transaction participants that are incapable ofcommunicating the heuristic response to the transaction coordinator andwhere the heuristic response from the transaction participant sent tothe transaction coordinator indicates that the transaction participantdetermined that it is unable to honor a transactional prior preparedcommitment made to the transaction coordinator by the transactionparticipant during a first prepare phase of a two-phase commitassociated with a transaction coordinated by the transaction coordinatoras requested by the application.
 2. The computer program product ofclaim 1, where, in causing the computer to provide, via the transactioncoordinator, the indication to the transaction participant as part ofthe message originating from the transaction coordinator, where themessage indicates that the transaction coordinator, that coordinatescommitment of transactions as requested by the application, supports theheuristic response from the transaction participant that is sent to thetransaction coordinator during coordination of the transactions asrequested by the application in response to the determination by thetransaction participant of the heuristic outcome, the computer readableprogram code when executed on the computer further causes the computerto: augment the message with a message element originating from thetransaction coordinator, where the message element indicates that thetransaction coordinator supports the heuristic response from thetransaction participant.
 3. The computer program product of claim 2,where, in causing the computer to augment the message with the messageelement originating from the transaction coordinator, the computerreadable program code when executed on the computer causes the computerto: augment a protocol message originating from the transactioncoordinator.
 4. The computer program product of claim 2, where themessage element comprises a coordination context inserted into anapplication initiated message by the transaction coordinator.
 5. Thecomputer program product of claim 4, where the coordination contextcomprises an identifier of the transaction, an endpoint reference (EPR)of a registration service of the transaction coordinator, andinformation about the transaction comprising transaction security andtransaction reliability.
 6. The computer program product of claim 2,where, in causing the computer to augment the message with the messageelement originating from the transaction coordinator, the computerreadable program code when executed on the computer causes the computerto: augment a protocol header of the message with the message element,where the message element indicates that the transaction coordinatorsupports the heuristic response from the transaction participant andwhere a payload of the message is unchanged by the indication to thetransaction participant as augmented within the protocol header of themessage with the message element.
 7. The computer program product ofclaim 1, where the message comprises one of a registration responsemessage and a prepare message.
 8. The computer program product of claim1, where the computer readable program code when executed on thecomputer further causes the computer to: receive the heuristic responsefrom the transaction participant in association with the coordinatedtransaction, where the heuristic response is received responsive to aheuristic decision by the transaction participant and where thetransaction participant is configured to remember the heuristic decisionuntil told by the transaction coordinator to forget the heuristicdecision; send a forget heuristic decision message to the transactionparticipant as initiation of a forget/forgotten heuristic decisionprotocol exchange; and receive a forgotten heuristic decision replymessage from the transaction participant as confirmation that thetransaction participant has discarded state information related to theheuristic decision and as completion of the forget/forgotten heuristicdecision protocol exchange.
 9. A method, comprising: providing, via atransaction coordinator, an indication to a transaction participant aspart of a message originating from the transaction coordinator, wherethe message indicates that the transaction coordinator, that coordinatescommitment of transactions as requested by an application, supports aheuristic response from the transaction participant that is sent to thetransaction coordinator during coordination of the transactions asrequested by the application in response to a determination by thetransaction participant of a heuristic outcome, where heuristic outcomescomprise situations where transaction participants determine they areunable to honor transactional prior prepared commitments made to thetransaction coordinator during first prepare phases of two-phase commitsassociated with the transactions, and the transactional prior preparedcommitments comprise indications to the transaction coordinator that thetransaction participants are prepared during the first prepare phases ofthe two-phase commits to commit respective portions of the transactionswhen instructed by the transaction coordinator, and where the message isignorable by transaction participants that are incapable ofcommunicating the heuristic response to the transaction coordinator andwhere the heuristic response from the transaction participant sent tothe transaction coordinator indicates that the transaction participantdetermined that it is unable to honor a transactional prior preparedcommitment made to the transaction coordinator by the transactionparticipant during a first prepare phase of a two-phase commitassociated with a transaction coordinated by the transaction coordinatoras requested by the application; and receiving the heuristic responsefrom the transaction participant in association with the coordinatedtransaction.
 10. The method of claim 9, where providing the indicationto the transaction participant that the transaction coordinator supportsthe heuristic response comprises: augmenting the message with a messageelement, where the message element comprises a coordination contextinserted into an application initiated message by the transactioncoordinator and where the coordination context comprises an identifierof the transaction, an endpoint reference (EPR) of a registrationservice of the transaction coordinator, and information about thetransaction comprising transaction security and transaction reliability.11. The method of claim 9, where providing the indication to thetransaction participant that the transaction coordinator supports theheuristic response comprises: augmenting a protocol header of themessage with a message element, where the message element indicates thatthe transaction coordinator supports the heuristic response from thetransaction participant and where a payload of the message is unchangedby the indication to the transaction participant as augmented within theprotocol header of the message with the message element.
 12. The methodof claim 9, where the message comprises one of a registration responsemessage and a prepare message.
 13. The method of claim 9, where theheuristic response is received responsive to a heuristic decision by thetransaction participant and where the transaction participant isconfigured to remember the heuristic decision until told by thetransaction coordinator to forget the heuristic decision, and furthercomprising: sending a forget heuristic decision message to thetransaction participant as initiation of a forget/forgotten heuristicdecision protocol exchange; and receiving a forgotten heuristic decisionreply message from the transaction participant as confirmation that thetransaction participant has discarded state information related to theheuristic decision and as completion of the forget/forgotten heuristicdecision protocol exchange.
 14. An apparatus, comprising: acommunication interface; and a processor programmed to execute atransaction manager associated with a transaction coordinator, where thetransaction manager is configured to: provide, via the transactioncoordinator, an indication to a transaction participant as part of amessage originating from the transaction coordinator via thecommunication interface, where the message indicates that thetransaction coordinator, that coordinates commitment of transactions asrequested by an application, supports a heuristic response from thetransaction participant that is sent to the transaction coordinatorduring coordination of the transactions as requested by the applicationin response to a determination by the transaction participant of aheuristic outcome, where heuristic outcomes comprise situations wheretransaction participants determine they are unable to honortransactional prior prepared commitments made to the transactioncoordinator during first prepare phases of two-phase commits associatedwith the transactions, and the transactional prior prepared commitmentscomprise indications to the transaction coordinator that the transactionparticipants are prepared during the first prepare phases of thetwo-phase commits to commit respective portions of the transactions wheninstructed by the transaction coordinator, and where the message isignorable by transaction participants that are incapable ofcommunicating the heuristic response to the transaction coordinator andwhere the heuristic response from the transaction participant sent tothe transaction coordinator indicates that the transaction participantdetermined that it is unable to honor a transactional prior preparedcommitment made to the transaction coordinator by the transactionparticipant during a first prepare phase of a two-phase commitassociated with a transaction coordinated by the transaction coordinatoras requested by the application; and receive the heuristic response fromthe transaction participant in association with the coordinatedtransaction.
 15. The apparatus of claim 14, where, in providing theindication to the transaction participant that the transactioncoordinator supports the heuristic response, the transaction manager isconfigured to: augment the message with a message element, where themessage element comprises a coordination context inserted into anapplication initiated message by the transaction coordinator and wherethe coordination context comprises an identifier of the transaction, anendpoint reference (EPR) of a registration service of the transactioncoordinator, and information about the transaction comprisingtransaction security and transaction reliability.
 16. The apparatus ofclaim 14, where, in providing the indication to the transactionparticipant that the transaction coordinator supports the heuristicresponse, the transaction manager is configured to: augment a protocolheader of the message with a message element, where the message elementindicates that the transaction coordinator supports the heuristicresponse from the transaction participant and where a payload of themessage is unchanged by the indication to the transaction participant asaugmented within the protocol header of the message with the messageelement.
 17. The apparatus of claim 14, where the message comprises oneof a registration response message and a prepare message.
 18. Theapparatus of claim 14, where the heuristic response is receivedresponsive to a heuristic decision by the transaction participant andwhere the transaction participant is configured to remember theheuristic decision until told by the transaction coordinator to forgetthe heuristic decision, and where the transaction manager is furtherconfigured to: send a forget heuristic decision message to thetransaction participant as initiation of a forget/forgotten heuristicdecision protocol exchange; and receive a forgotten heuristic decisionreply message from the transaction participant as confirmation that thetransaction participant has discarded state information related to theheuristic decision and as completion of the forget/forgotten heuristicdecision protocol exchange.